Common Understanding Wiki

Common Understanding Wiki

A Common Knowledge Source of Terms and Definitions

Evaluation...

Process Mining Engine

(You are viewing an archived version of this page. (1.9), Go to the latest version.)

Summary

The Process Mining Engine is a composite component in the BPaaS Evaluation Environment which is responsible for executing process mining algorithms over the execution history of a BPaaS stored in the Semantic KB. This component is invoked by the Hybrid Dashboard to execute this required type of BPaaS analysis and visualise the respective analysis results according to the best possible visualisation metaphor.

While various kinds of process mining algorithms exist, we have selected to re-use only one kind for the moment. This kind maps to the recreation of a process model from the process log. This kind is quite useful for the optimisation of the BPaaS modelling as it enables to check which paths in the BPaaS workflow model are frequently executed, which are scarcely executed and which are not at all. As such, this can signify an indication to the modeller that possibly the paths that are never followed do not need to be modelled anymore. Concerning the other kinds of process mining algorithms that we intended to support, which include decision and organisational mining, they were not integrated for some technical reasons mapping mainly to the lack of some required data that could be collected from particular information sources in the CloudSocket platform (see D3.6 for more details). On the other hand, we do support semantic process mining as we can exploit semantic annotations over tasks in order to improve the accuracy of the process mining algorithms currently exploited.

The process model re-creation algorithms that we exploit come from the ProM process mining framework and constitute state-of-the-art algorithms. They are exploited as they are by appropriately creating a log from the Semantic KB mapping to the execution history of a certain BPaaS (either solely coupled to a specific customer or across all customers of that BPaaS) and then passing that log as input to these algorithms. This log conforms to the XES standard. Depending on the broker choice, this log can be formed by including either the names of the BPaaS workflow tasks in the log entries or the names of the concepts which have been used to annotate these workflow tasks. Upon successful execution, the result of each algorithm is then transformed again by exploiting the facilities of the ProM framework into a file conforming to BPMN which is the de facto standard adopted by CloudSocket.

As enabled as a feature by the Harvesting Engine, the Process Mining Engine does support multi-tenancy as it allows each broker to focus the analysis only on its own fragment in the Semantic KB. The whole process mining functionality is encapsulated for that reason in the form of a REST API which does take as input the id of the broker for which the analysis has to be performed. Apart from the core process mining functionality, this REST API offers a utility function that lists all state-of-the-art process mining algorithms that can be exploited by the broker. In this sense, via the interaction with the Hybrid Business Dashboard, the broker is listed with all these algorithms, he/she can select the one that is desired by him/her and then initiate its execution.

The Process Mining Engine can be easily replaced by another component developed externally by an organisation outside the CloudSocket consortium. This is due to the fact that this component is not tightly coupled with any other internal component in the BPaaS Evaluation Environment. It just communicates with the Semantic KB in order to retrieve the execution history of a certain BPaaS and exposes an API to the Hybrid Business Dashboard in order to enable its functionality to be invoked. In this sense, any replacement component would just have to conform to that API as well as be able to draw the correct information from the context of the Semantic KB.

The following table indicates the details of the component.

Type of ownership Creation
Original tool ProM Process Mining Framework
Planned OS license Mozilla Public Licence 2.0.
Reference community ADOxx Community.


Consist of

  • Process Mining Service (REST API exposing the core functionality of this engine)

Depends on

  • Semantic KB

Component responsible

Developer Email Company
Kyriakos Kritikos kritikos@ics.forth.gr FORTH

Architecture Design

The Process Mining Engine is is coloured in blue in the overall BPaaS Evaluation Environment architecture depicted in the figure below. As it can be seen, it is invoked by the Business Management Tool in order to invoke the right state-of-the-art process mining algorithm. This invocation, in turn, leads to exploiting the content of the Semantic KB at the Data Layer in order to support the creation of the log to be mined.

The final, internal architecture of the Process Mining Engine, which is depicted below, comprises the following 5 main components:

  • Process Mining Service: A REST service which encapsulates the whole functionality of the Process Mining Engine in the form of REST API methods. Each method invoked triggers the execution of the Process Mining Orchestrator.
  • Process Mining Orchestrator takes care of orchestrating the execution of the rest of the components in the architecture in order to support the satisfaction of the process mining request. For each process mining request, this component first invokes the Query Creator to create a SPARQL query which is then issued over the Semantic KB. The query result is then used to invoke the Log Creator in order to produce the required log which is exploited to execute the process mining algorithm selected from the Process Mining Library. The mining result is then transformed into BPMN form by exploiting a certain transformation algorithm from the Process Mining Library depending on the original form of the output supported by the executed process mining algorithm.
  • Query Creator: this component, depending on the broker input which designates the BPaaS to be mined and optionally: (a) the customer to which the analysis should be restrained, (b) the period of the execution history and (c) whether semantic mining is to be performed, dynamically creates the right SPARQL query which can be issued over the Semantic KB in order to accurately obtain the right process log-oriented information to be used for the mining.
  • Log Creator: this component takes the result of the SPARQL query execution and creates a log out of it which conforms to the XES standard. Depending on whether normal or semantic process mining needs to be supported, either the BPaaS workflow task names or their annotations are used to populate each entry of the log.
  • Process Mining Library: this library has been constructed by exploiting some state-of-the-art process mining algorithms from ProM as well as the needed transformation algorithms (e.g., from petri net to BPMN) from the same framework that guarantee the final production of a BPMN recreated process model.  
pm.png
Architecture of the Process Mining Engine.

Installation Manual

The component has been implemented purely in java. It depends on other external components / frameworks like ProM, Spring, swagger, jersey and sesame/open rdf. The following figure explicates the sole artefact generated mapping to this component as well as its dependencies on other artefacts (at a coarse-grained level to simplify the figure).

pm-artifacts.png

Artifact dependencies for the Process Mining Engine.

Maven has been exploited as the main build automation tool, prescribing how the component/artefact can be built and its main dependencies. Such a tool facilitates the building and automatic generation of this artefact for the different CloudSocket environments (development and production) and their configuration. A complete description of how such artefact building and generation can be performed for the different environments is given in the installation manual below.

Development

Currently, the following requirements hold for this component:

  • Oracle's 1.7.x JDK or higher
  • Apache tomcat 1.7 or higher
  • Maven tool for code compilation and packaging

The installation procedure to be followed is the one given below:

  1. Download source code from https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/evaluation_skb/repository/archive.tar?ref=master
  2. Unzip code with tar (or any other tool)
  3. Go to the root directory of the installed code
  4. Change the configuration file to provide the right access information for the Virtuoso Triple Store (https://virtuoso.openlinksw.com/)
  5. Run:
    mvn clean install
    
    and then:
    mvn war:war
    
  6. Move the war file to the webapps directory of tomcat and start tomcat, if not yet started
  7. Test installation by entering in your browser the following URL: http://localhost:8080/evaluation/

Production

The same instructions as above hold for this component

Test Cases

You can run test cases directly from the URL (http://localhost:8080/evaluation in your development environment) of the REST service due to the use of swagger (http://swagger.io) which enables the execution of the API method exposed by exploiting user input provided in a form-based manner. The following test cases are envisioned:

  • Run a KPI evaluation query

Suppose that the user desires to obtain the most recent value for a KPI named as "MeanAvailabilityKPI". Then, he/she can browse the methods of the API and click on the one named as "evaluateKPI". The following screenshot indicates the upper part of the description of the method when selected: kpiQuery1.PNG Next, he/she can fill in the kpiName field with the value of "MeanAvailabilityKPI", the field of "brokerId" with the value of "bwcon" and the field of "bundleId" with the value of "SendInvoiceSaaSEurope". Then he/she can press the "Try it out!" button.

Finally, he/she will be able to see the respective curl command issued, the request URL, the corresponding results, as well as the response status and headers as indicated in the following figure: kpiQuery3.png

User Manual

API Specification

The reader should refer to the API web page of swagger for browsing an on-line documentation with the capability to execute the API methods. In the following, the API methods of the Conceptual Analytics Service are analysed below:

evaluateKPI

This method enables to produce current and historical measurements for a certain KPI in the context of a specific BPaaS. As multi-tenancy is supported, the id of the broker needs to be specified in order to set the appropriate context for the method execution.

POST ca/evaluateKPI/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

  • brokerId: denotes the id of the broker for which the evaluation needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
  • bundleId: denotes the id of the BPaaS bundle for which the evaluation needs to be performed (optional)
  • kpiName: denotes the name of the KPI to be evaluated (obligatory)
  • kpiPeriod: denotes the (history) period of the evaluation. If this parameter is specified, then a set of KPI evaluation values and not just one can be returned matching the respective period provided. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)
  • tenant: denotes the id of the tenant for which the KPI can be evaluated. In this way, the KPI is assessed only for this tenant and not across all tenants that have purchased the respective BPaaS (optional)
  • maxRows: denotes the maximum number of KPI values to return. Default value is 0 indicating that all possible values can be returned (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

  • 200 -- The method execution was successful
  • 400 -- Wrong parameter values have been provided
  • 404 -- The resource requested (i.e., the broker) was not found
  • 406 -- The format requested for the method output is not supported

The output can be in both json and xml formats. A sample for a json output is given below:

{
  "results": [
    {
      "bundleId": "SendInvoiceSaaSEurope",
      "value": "0.8010364041400798e0",
      "instant": "2016-01-27T11:43:38.588Z"
    }
  ]
}
evaluateMetric

This method enables the production of current and historic measurements for a KPI metric. It is similar to the "evaluateKPI" method but requires from the broker to appropriately specify the KPI metric in two different ways: (a) the metric and its context are passed as input parameters; (b) the name of an existing metric is provided:

POST ca/evaluateMetric/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

  • brokerId: denotes the id of the broker for which the evaluation needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
  • metricName: denotes the name of the existing metric for which the evaluation needs to be performed. This parameter is optional as there is an alternative way of determining the KPI metric to be evaluated (optional)
  • metric: provides a CompositeMetric specification in OWL-Q for the metric to be evaluated. As a composite metric is associated to a specific metric context, the "metricContext" parameter does not need to be provided in this case (optional)
  • metricContext: provides the MetricContext specification in OWL-Q for the metric to be evaluated. This metric context includes scheduling and window information for the metric at hand. This parameter is optional and might be provided in case that we need to modify the context of an existing metric (whose name is specified in the "metricName" parameter) temporarily for the context of this evaluation (optional)
  • bundleId: denotes the id of the BPaaS bundle for which the evaluation needs to be performed (optional)
  • kpiPeriod: denotes the (history) period of the evaluation. If this parameter is specified, then a set of metric measurement values and not just one can be returned matching the respective period provided. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)
  • tenant: denotes the id of the tenant for which the identified metric can be evaluated. In this way, the metric measurements are only produced for this tenant and not across all tenants that have purchased the respective BPaaS (optional)
  • maxRows: denotes the maximum number of metric measurements values to return. Default value is 0 indicating that all possible values can be returned (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

  • 200 -- The method execution was successful
  • 400 -- Wrong parameter values have been provided
  • 404 -- The resource requested (i.e., the broker) was not found
  • 406 -- The format requested for the method output is not supported

The output can be in both json and xml formats. A sample for a json output is given below:

{
  "results": [
    {
      "bundleId": "SendInvoiceSaaSEurope",
      "value": "0.8010364041400798e0",
      "instant": "2016-01-27T11:43:38.588Z"
    }
  ]
}
kpiDrillDown

This method enables to perform a drill-down over a certain KPI for a specific BPaaS (again under the context of a specific broker). The drill-down results can be provided in a tree-based form in both JSON & XML formats, where each result contains information which is equivalent to that of the aforementioned methods:

POST ca/kpiDrillDown/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

  • brokerId: denotes the id of the broker for which the KPI drill-down needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
  • bundleId: denotes the id of the BPaaS bundle for which the KPI drill-down needs to be performed (optional)
  • kpiName: denotes the name of the KPI for which the KPI drill-down needs to be performed (obligatory)
  • kpiPeriod: denotes the (history) period of the drill-down. If this parameter is specified, then a set of drill-down values and not just one can be returned matching the respective period provided. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)
  • tenant: denotes the id of the tenant for which the identified KPI needs to be drilled down. In this way, the respective KPI measurements and their drill-down are only produced for this tenant and not across all tenants that have purchased the respective BPaaS (optional)
  • maxRows: denotes the maximum number of drill-down values to return. Default value is 0 indicating that all possible values can be returned (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

  • 200 -- The method execution was successful
  • 400 -- Wrong parameter values have been provided
  • 404 -- The resource requested (i.e., the broker) was not found
  • 406 -- The format requested for the method output is not supported

The output can be in both json and xml formats. A sample for a json output is given below:

{
  "results": [
    {
      "bundleId": "SendInvoiceSaaSEurope",
      "kpi": "MeanKPIAvailability",
      "value": "0.8010364041400798e0",
      "instant": "2016-01-27T11:43:38.588Z",
      "subRows": [
        {
         "bundleId": "SendInvoiceSaaSEurope",
         "kpi": "MeanIaaSKPIAvailability",
         "value": "0.8526374638629035e0",
         "instant": "2016-01-27T11:43:37.466Z",
         "subRows": []
        } 
      ]
    }
  ]
}
kpiHistory

This method enables to query the historical measurements for a certain KPI in the context of a specific BPaaS. As multi-tenancy is supported, the id of the broker needs to be specified in order to set the appropriate context for the method execution. The results are equivalent to those returned by the "evaluateKPI" method. Please note that the content of the history fragment of the broker concerned needs to be populated via the "evaluateKPI" method in order to be able to obtain any result.

POST ca/kpiHistory/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

  • brokerId: denotes the id of the broker for which the historical query over the broker-specific historical fragment needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
  • bundleId: denotes the id of the BPaaS bundle for which the historical query needs to be performed (optional)
  • kpiName: denotes the name of the KPI for which historical measurements need to be obtained (obligatory)
  • kpiPeriod: denotes the (history) period. If this parameter is specified, then a set of KPI historical measurement values and not just one can be returned matching the respective period provided. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)
  • tenant: denotes the id of the tenant for which the KPI history query can be evaluated. In this way, the required historical KPI values to be retrieved map only to this tenant and do not cross all tenants that have purchased the respective BPaaS (optional)
  • maxRows: denotes the maximum number of KPI historical measurement values to return. Default value is 0 indicating that all possible values can be returned (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

  • 200 -- The method execution was successful
  • 400 -- Wrong parameter values have been provided
  • 404 -- The resource requested (i.e., the broker) was not found
  • 406 -- The format requested for the method output is not supported

The output can be in both json and xml formats. A sample for a json output is given below:

{
  "results": [
    {
      "bundleId": "SendInvoiceSaaSEurope",
      "value": "0.8010364041400798e0",
      "instant": "2016-01-27T11:43:38.588Z"
    }
  ]
}
kpiQuery

This method enables to retrieve the list of KPIs that have been defined in the context of a specific broker. When the id of the BPaaS is also provided, then the KPI list is filtered to include only those KPIs that have been specified for the BPaaS.

POST ca/kpiQuery/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

  • brokerId: denotes the id of the broker for which the KPI query needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
  • bundleId: denotes the id of the BPaaS bundle for which the defined KPIs need to be retrieved - as stated, if not given, then this maps to obtaining all the KPIs that have been defined for all BPaaSes of a certain broker (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

  • 200 -- The method execution was successful
  • 400 -- Wrong parameter values have been provided
  • 404 -- The resource requested (i.e., the broker) was not found
  • 406 -- The format requested for the method output is not supported

The output can be in both json and xml formats. A sample for a json output is given below:

[
  {
    "name": "MeanIaaSAvailabilityKPI",
    "description": null,
    "abbreviation": null,
    "synonym": null,
    "constraintContext": null,
    "obliged": null,
    "firstArgument": {
      "name": "MeanIaaSAvailability",
      "description": null,
      "abbreviation": null,
      "synonym": null,
      "scale": null,
      "monotonicity": "POSITIVE",
      "unit": null,
      "valueType": null,
      "aggregationType": null,
      "measuredObject": "http://www.cloudsocket.eu/evaluation#IaaS1",
      "attribute": null,
      "level": 2,
      "metricContext": {
        "name": "MC1",
        "description": null,
        "abbreviation": null,
        "synonym": null,
        "window": null,
        "schedule": {
          "name": "OneDaySchedule",
          "description": null,
          "abbreviation": null,
          "synonym": null,
          "interval": 1,
          "repetition": 0,
          "scheduleType": "FIXED_RATE",
          "timeUnit": {
            "name": "Day",
            "description": null,
            "abbreviation": null,
            "synonym": null,
            "scale": null,
            "monotonicity": null,
            "quantity": null,
            "quantityKind": null,
            "unitType": "SINGLE",
            "unitMappings": null,
            "uri": "http://www.cloudsocket.eu/evaluation#Day"
          },
          "uri": "http://www.cloudsocket.eu/evaluation#OneDaySchedule"
        },
        "uri": "http://www.cloudsocket.eu/evaluation#MC1"
      },
      "formula": {
        "name": "mean_iaas_availability",
        "description": null,
        "abbreviation": null,
        "synonym": null,
        "function": "MEAN",
        "functionURI": null,
        "argumentList": [
          {
            "RawMetric": {
              "name": "IaaSAvailability",
              "description": null,
              "abbreviation": null,
              "synonym": null,
              "scale": null,
              "monotonicity": "POSITIVE",
              "unit": null,
              "valueType": null,
              "aggregationType": null,
              "measuredObject": "http://www.cloudsocket.eu/evaluation#IaaS1",
              "attribute": null,
              "level": 1,
              "metricContext": null,
              "sensor": null,
              "measurementDirective": null,
              "manual": true,
              "uri": "http://www.cloudsocket.eu/metrics/IaaSAvailability"
            }
          }
        ],
        "uri": "http://www.cloudsocket.eu/formulas/mean_iaas_availability"
      },
      "metricList": [
        {
          "RawMetric": {
            "name": "IaaSAvailability",
            "description": null,
            "abbreviation": null,
            "synonym": null,
            "scale": null,
            "monotonicity": "POSITIVE",
            "unit": null,
            "valueType": null,
            "aggregationType": null,
            "measuredObject": "http://www.cloudsocket.eu/evaluation#IaaS1",
            "attribute": null,
            "level": 1,
            "metricContext": null,
            "sensor": null,
            "measurementDirective": null,
            "manual": true,
            "uri": "http://www.cloudsocket.eu/metrics/IaaSAvailability"
          }
        }
      ],
      "uri": "http://www.cloudsocket.eu/metrics/MeanIaaSAvailability"
    },
    "comparisonOperator": "GREATER_EQUAL_THAN",
    "optimisationOperator": null,
    "secondArgument": 0.9,
    "warningThreshold": 0.8,
    "validity": null,
    "childKPIs": null,
    "bundleURI": "http://www.cloudsocket.eu/evaluation/bwcon#SendInvoice",
    "qualifyingCondition": false,
    "uri": "http://www.cloudsocket.eu/kpis/MeanIaaSAvailabilityKPI"
  }
]
kpiTenantQuery

This method enables to retrieve the list of tenants/customers for which there exist measurements for a certain KPI for the BPaaSes that they have purchased in the context of a specific broker. When the id of the BPaaS is also provided, then the tenant list is filtered to include only those tenants which have purchased the respective BPaaS.

POST ca/kpiTenantQuery/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

  • brokerId: denotes the id of the broker for which the KPI tenant query needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
  • bundleId: denotes the id of the BPaaS bundle that must have been purchased by the tenants to be returned (optional)
  • kpiName: denotes the name of the KPI for which measurements should have been produced for the tenants to be returned (obligatory)
  • kpiPeriod: denotes the historical period for which KPI measurements should have been produced. The value should conform to String-based Java periods (e.g., "P1M" which declares a period of 1 month until now) (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

  • 200 -- The method execution was successful
  • 400 -- Wrong parameter values have been provided
  • 404 -- The resource requested (i.e., the broker) was not found
  • 406 -- The format requested for the method output is not supported
  • 500 -- Internal server error exception

The output can be in both json and xml formats. A sample for a json output is given below:

[
  {
    3c1ab6ac-6a7e-4791-8c16-f8f6d400231c
  }
]
ldQuery

This method enables to pose an arbitrary query over the broker-specific fragment of the Semantic KB. Such a query should only be posed by an expert on semantic technologies which should have an appropriate knowledge of SPARQL as well as of the Evaluation and OWL-Q (KPI Extension) ontologies that have been developed in the context of WP3 in CloudSocket.

POST ca/ldQuery/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

  • brokerId: denotes the id of the broker for which the KPI tenant query needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
  • query: signifies the SPARQL query to be posed over the Semantic KB (obligatory)
  • timeout: specifies the maximum amount time for waiting (in milliseconds) until a response can be obtained from the Semantic KB. A value of 0, which is the default, denotes that the broker can wait indefinitely (optional)
  • maxRows: denotes the maximum number of rows to be produced by the query. A value of 0, which is the default, denotes that all rows should be returned. As SPARQL has the LIMIT construct, the broker should be careful of not specifying SPARQL queries including this construct that are evaluated via this method for which has a positive value for this parameter has been provided. In this latter case, the outcome would depend on the correlation between the values for the LIMIT construct and this parameter, i.e., if LIMIT is X and parameter value is Y, >= X, then X values will be returned. If Y < X, then Y values will be returned. In other words, the lowest from the values provided will prevail (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

  • 200 -- The method execution was successful
  • 400 -- Wrong parameter values have been provided
  • 404 -- The resource requested (i.e., the broker) was not found
  • 406 -- The format requested for the method output is not supported

The output can be in "application/sparql-results+xml", "application/sparql-results+json", "text/csv" and "text/tab-separated-values". A sample for the "application/sparql-results+json" output is given below:

{ "head": { "link": [], "vars": ["bpaas", "id"] },
  "results": { "distinct": false, "ordered": true, "bindings": [
    { "bpaas": { "type": "uri", "value": "http://www.cloudsocket.eu/evaluation#BPaaS_bwcon_SendInvoiceSaaSEurope" }	, "id": { "type": "typed-literal", "datatype": "http://www.w3.org/2001/XMLSchema#string", "value": "SendInvoiceSaaSEurope" }},
    { "bpaas": { "type": "uri", "value": "http://www.cloudsocket.eu/evaluation#BPaaS_bwcon_SendInvoiceSaaSWorldwide" }	, "id": { "type": "typed-literal", "datatype": "http://www.w3.org/2001/XMLSchema#string", "value": "SendInvoiceSaaSWorldwide" }},
    { "bpaas": { "type": "uri", "value": "http://www.cloudsocket.eu/evaluation#BPaaS_bwcon_SendInvoiceIaaSEurope" }	, "id": { "type": "typed-literal", "datatype": "http://www.w3.org/2001/XMLSchema#string", "value": "SendInvoiceIaaSEurope" }} ] } }
rawMetricQuery

This method enables to obtain all the raw metrics that have been defined in OWL-Q for a certain broker. In case that a respective BPaaS is also determined, then the raw metric list is filtered to contain only those raw metrics that have been defined for this BPaaS. As has been already stated, this method is a utility one which enables the broker to construct KPI metric specifications out of those returned by this method in order to subsequently make evaluation queries for those KPI metrics via the "evaluateMetric" method and thus better explore the possible KPI metric space.

POST ca/rawMetricQuery/{brokerId}

The expected input format is multipart/form-data. The following input parameters are expected:

  • brokerId: denotes the id of the broker for which the raw metric query needs to be performed. It is a path parameter as it can be seen from the method relative URL (obligatory)
  • bundleId: denotes the id of the BPaaS bundle in order to restrain the raw metric list to be obtained to contain only those metrics that have been defined for this bundle (optional)

The following response codes can be returned depending on whether the API method execution was successful or not:

  • 200 -- The method execution was successful
  • 400 -- Wrong parameter values have been provided
  • 404 -- The resource requested (i.e., the broker) was not found

The output can be in XML or JSON form. A sample of an output in JSON form is given below:

[
  {
    "name": "CycleTime",
    "description": null,
    "abbreviation": null,
    "synonym": null,
    "scale": null,
    "monotonicity": "NEGATIVE",
    "unit": null,
    "valueType": null,
    "aggregationType": null,
    "measuredObject": "http://www.cloudsocket.eu/evaluation#Workflow_SendInvoice",
    "attribute": null,
    "level": 1,
    "metricContext": null,
    "sensor": null,
    "measurementDirective": null,
    "manual": true,
    "uri": "http://www.cloudsocket.eu/metrics/CycleTime"
  },
  {
    "name": "EmailNotSent",
    "description": null,
    "abbreviation": null,
    "synonym": null,
    "scale": null,
    "monotonicity": "NEGATIVE",
    "unit": null,
    "valueType": null,
    "aggregationType": null,
    "measuredObject": "http://www.cloudsocket.eu/evaluation#Workflow_SendInvoice",
    "attribute": null,
    "level": 1,
    "metricContext": null,
    "sensor": null,
    "measurementDirective": null,
    "manual": true,
    "uri": "http://www.cloudsocket.eu/metrics/EmailNotSent"
  },
  {
    "name": "EmailSent",
    "description": null,
    "abbreviation": null,
    "synonym": null,
    "scale": null,
    "monotonicity": "POSITIVE",
    "unit": null,
    "valueType": null,
    "aggregationType": null,
    "measuredObject": "http://www.cloudsocket.eu/evaluation#Workflow_SendInvoice",
    "attribute": null,
    "level": 1,
    "metricContext": null,
    "sensor": null,
    "measurementDirective": null,
    "manual": true,
    "uri": "http://www.cloudsocket.eu/metrics/EmailSent"
  },
  {
    "name": "SaaSAvailability",
    "description": null,
    "abbreviation": null,
    "synonym": null,
    "scale": null,
    "monotonicity": "POSITIVE",
    "unit": null,
    "valueType": null,
    "aggregationType": null,
    "measuredObject": "http://www.cloudsocket.eu/evaluation#ExternalSaaS1",
    "attribute": null,
    "level": 1,
    "metricContext": null,
    "sensor": null,
    "measurementDirective": null,
    "manual": true,
    "uri": "http://www.cloudsocket.eu/metrics/SaaSAvailability"
  },
  {
    "name": "CustomerSatisfaction",
    "description": null,
    "abbreviation": null,
    "synonym": null,
    "scale": null,
    "monotonicity": "POSITIVE",
    "unit": null,
    "valueType": null,
    "aggregationType": null,
    "measuredObject": "http://www.cloudsocket.eu/evaluation#Workflow_SendInvoice",
    "attribute": null,
    "level": 1,
    "metricContext": null,
    "sensor": null,
    "measurementDirective": null,
    "manual": true,
    "uri": "http://www.cloudsocket.eu/metrics/CustomerSatisfaction"
  },
  {
    "name": "IaaSAvailability",
    "description": null,
    "abbreviation": null,
    "synonym": null,
    "scale": null,
    "monotonicity": "POSITIVE",
    "unit": null,
    "valueType": null,
    "aggregationType": null,
    "measuredObject": "http://www.cloudsocket.eu/evaluation#IaaS1",
    "attribute": null,
    "level": 1,
    "metricContext": null,
    "sensor": null,
    "measurementDirective": null,
    "manual": true,
    "uri": "http://www.cloudsocket.eu/metrics/IaaSAvailability"
  }
]

Handbook

3 Attachments
55411 Views
Average (0 Votes)
Comments
No comments yet. Be the first.